Optimizing the number and type of database backups to achieve a given recovery time objective (rto)

ABSTRACT

A method of optimizing the number and type of database backups to achieve a given RTO is provided and may include receiving a RTO and receiving a heuristic for determining an amount of unencumbered processing time. A type of next backup, (i.e., a next backup), is determined wherein the type of next backup is an incremental backup when the sum of the heuristic, and the times to: restore the latest full backup, restore zero or more incremental backups, complete a current incremental backup, and perform a full backup is less than the received RTO, else the type of the next backup is a full backup. A time to schedule the next backup is scheduled based on the received RTO being a total of an amount of time to: complete the type of next backup; rollforward zero or more transaction log records; and to restore at least one backup.

FIELD

The present disclosure relates generally to the field of computersystems, and more particularly, to database backup and recoveryoperations.

BACKGROUND

A Database Management System (DBMS) stores large volumes of data tosupport diverse workloads and heterogeneous applications. The DBMS iscritical to business transaction processing and decision making, and mayincorporate strategies that promote keeping the data highly available.However, a DBMS may unexpectedly fail for various reasons, includingdefects in a hardware or software component within a computer system.

A DBMS may perform many complex operations, consisting of multiplesteps, such as for example, creating a new table. The amount of workrequired to complete an operation varies, and may depend upon suchfactors as the algorithms and architecture chosen by the DBMS vendor toimplement product features. Similarly, the time required to recover anoperation (i.e., replay from the log) varies by the type of operation.For example, a table reorganization operation is much more complex,i.e., takes more steps to complete, than an operation to insert a row ofdata in a table, and consequently will take much longer to recover. Arecovery cost is not a simple linear function that is based solely onthe amount of data and a number of operations, but is also dependent onthe type of workloads and the complexity of the operations that areexecuted. The nonlinear nature of database operations makes itchallenging for a Database Administrator (DBA) to predict the time itwill take to perform a future recovery operation. Consequently, the DBAmay often rely on a combination of intuition, trial and error, andexperience when designing a recovery plan to meet the businessenterprise's Recovery Time Objective (RTO), which may be referred to asa maximum length of time that a DBMS may remain unavailable following aservice disruption.

One solution that the DBA may often choose is to back up the DBMS morefrequently than required, rather than risk a situation where thebusiness may miss the RTO goal or be unable to meet a Service LevelAgreement with an end user community. This problem becomes morepronounced in a cloud environment where the volume of data tends to behigh, the types of workloads accessing the data tend to be much morediverse, and there tends to be fewer DBAs available to manage theinstallation.

BRIEF SUMMARY

Among other things, a method and system of optimizing the number andtype of database backups to achieve a given RTO is provided. Accordingto an embodiment of the invention, a method of optimizing the number andtype of database backups to achieve a given RTO may include receiving aRTO; receiving a heuristic for determining an amount of unencumberedprocessing time; determining a type of next backup corresponding to anext backup, wherein the type of next backup is an incremental backupwhen a sum of recovery times totals less than the received RTO, else thetype of the next backup is a full backup; and determining a time toschedule the next backup based on the received RTO being a total of: anamount of time to complete the type of next backup; an amount of time torollforward zero or more transaction log records; and an amount of timeto restore at least one backup.

In another embodiment of the invention, a computer program product foroptimizing the number and type of database backups to achieve a givenRTO may be provided. The computer program product may include a DBMSembodied on a computer readable storage medium. The DBMS may includecode executable by a processor to perform a method that may includereceiving an RTO; receiving a heuristic for determining an amount ofunencumbered processing time; determining a type of next backupcorresponding to a next backup, wherein the type of next backup is anincremental backup when a sum of recovery times totals less than thereceived RTO, else the type of the next backup is a full backup; anddetermining a time to schedule the next backup based on the received RTObeing a total of: an amount of time to complete the type of next backup;an amount of time to rollforward zero or more transaction log records;and an amount of time to restore at least one backup.

In another embodiment of the invention, a computer system for optimizingthe number and type of database backups to achieve a given RTO isprovided. The computer system may include one or more processors, one ormore computer-readable storage devices, and a plurality of programinstructions stored on at least one of the one or more storage devicesfor execution by at least one of the one or more processors. Theplurality of program instructions may include program instructions toreceive a RTO; program instructions to receiving a heuristic fordetermining an amount of unencumbered processing time; programinstruction for determining a type of next backup corresponding to anext backup, wherein the type of next backup is an incremental backupwhen a sum of recovery times totals less than the received RTO, else thetype of the next backup is a full backup; and program instructions fordetermining a time to schedule the next backup based on the received RTObeing a total of: an amount time to complete the type of next backup; anamount time to rollforward zero or more transaction log records; and anamount time to restore at least one backup.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

These and other objects, features and advantages of the presentinvention will become apparent from the following detailed descriptionof illustrative embodiments thereof, which is to be read in connectionwith the accompanying drawings. The various features of the drawings arenot to scale as the illustrations are for clarity in facilitating oneskilled in the art in understanding the invention in conjunction withthe detailed description. In the drawings:

FIG. 1 is a block diagram illustrating an exemplary embodiment of asystem for optimizing a number and a type of database backups to achievea given Recovery Time Objective (RTO);

FIG. 2 is a flow diagram illustrating an overview of an exemplaryembodiment of a method of optimizing the number and type of databasebackup to achieve a given RTO;

FIG. 3 is a flow diagram illustrating an exemplary embodiment of amethod of determining a type of backup to initiate next;

FIG. 4 is a flow diagram illustrating an exemplary embodiment of amethod of determining when to initiate the next backup activity; and

FIG. 5 is a schematic block diagram of hardware and software of thecomputer environment according to an embodiment of the method of FIG. 2.

DETAILED DESCRIPTION

Embodiments of the present invention will now be described withreference to the figures. Referring to FIGS. 1 and 2, a system 100 andmethod 200 provide an exemplary implementation for optimizing the numberand type of database backups to achieve a given Recovery Time Objective(RTO).

FIG. 1 is a block diagram illustrating an exemplary embodiment of asystem 100 for optimizing the number and type of database backups toachieve a given RTO. The networked system 100 includes a server 102. Theserver 102 may also be connected to other computers and servers via anetwork 130. In general, the network 130 may be a telecommunicationsnetwork and/or a wide area network (WAN). In a particular embodiment,the network 130 is the Internet.

The server 102 generally includes a processor 104 connected via a bus120 to a memory 106, a network interface device 118, a storage 114, aninput device 122, and an output device 124. The server 102 is generallyunder the control of an operating system 108, such as for example Linux.More generally, any operating system supporting the functions disclosedherein may be used. The processor 104 is included to be representativeof a single CPU, multiple CPUs, a single CPU having multiple processingcores, and the like. Similarly, the memory 106 may be a random accessmemory. While the memory 106 is shown as a single identity, it should beunderstood that the memory 106 may comprise a plurality of modules, andthat the memory 106 may exist at multiple levels, from high speedregisters and caches to lower speed but larger DRAM chips. The networkinterface device 118 may be any type of network communications deviceallowing the server 102 to communicate with other computers via thenetwork 130.

The storage 114 may be a persistent storage device. Although the storage114 is shown as a single unit, the storage 114 may be a combination offixed and/or removable storage devices, such as fixed disc drives, solidstate drives, floppy disc drives, tape drives, removable memory cards oroptical storage. The memory 106 and the storage 114 may be part of onevirtual address space spanning multiple primary and secondary storagedevices.

The input device 122 may be any device for providing input to the server102. For example, a keyboard and/or a mouse may be used. The outputdevice 124 may be any device for providing output to a user of theserver 102. For example, the output device 116 may be any conventionaldisplay screen or set of speakers. Although shown separately from theinput device 122, the output device 124 and input device 122 may becombined. For example, a display screen with an integrated touch-screenmay be used.

As shown, the memory 106 of the server 102 includes a DBMS 110configured to manage one or more databases 115, contained in the storage114 of the server 102. Each database 115 may store data used by oneapplication, or alternatively, several applications may share more thanone database. As shown, the memory 106 of server 102 also contains atransaction log 112, which records sufficient information (i.e.,transaction log records) for the DBMS to restore the database to aconsistent state in case of a service disruption. In an exemplaryembodiment, the transaction log records may contain a timestamp, atransaction id, a database page identifier, a checksum value, a valueidentifying an operation name, pointers to other related transaction logrecords, and may further contain an image of the data both before andafter the modification. Embodiments of the invention may include anymechanism for maintaining timing and sequencing in place of a timestamp.

The particular description in FIG. 1 is for illustrative purposes only;it should be understood that the invention is not limited to specificdescribed embodiments, and any combination is contemplated to implementand practice the invention.

Referring now to FIG. 2, the reference numeral 200 generally designatesa flow diagram illustrating an overview of an exemplary method ofoptimizing the number and type of database backups to achieve a givenRTO.

At 205, a user-defined RTO is configured for one or more databases, orglobally for the DBMS. The value for the RTO is specified as a unit oftime, such as for example four hours, that defines a maximum tolerableamount of time that a database may remain unavailable following aservice disruption before the business enterprise is negativelyimpacted.

At 210, one or more DBMS processes may perform calculations, depicted inFIG. 3 and discussed further below, to determine a type of databasebackup (e.g., full or incremental) to execute during the next backupcycle. While either type of backup may be taken while the database isonline, if the amount of changed data is small compared to the over allsize of the database it may be more efficient to execute an incrementalbackup rather than a full backup.

To meet the RTO, at 215 one or more DBMS processes may performcalculations, depicted in FIG. 4 and discussed further below, todetermine when to initiate the next backup.

Generally, at 225 the method depicted in FIG. 2 may iteratively executeas a background administrative task. Therefore, at 225 where thedatabase is online, the one or more DBMS processes execute to determinea type of database backup to execute during the next backup cycle and toperform calculations to determine when to initiate the next backup.

Referring now to FIG. 3, the reference numeral 210 generally designatesa flow diagram illustrating an exemplary embodiment of a method ofdetermining a type of backup to initiate next. The following formula,discussed in detail during the discussion of FIG. 3, provides anexemplary calculation for determining the type of backup to initiatenext:

$\begin{matrix}\left( {{FRT} + {\sum\limits_{i = 1}^{n}{IRTi}} + {2({IBT})} + {FBT}} \right) & \left( {{Calculation}\mspace{14mu} 1} \right)\end{matrix}$

In general, there are several options from which to choose when creatinga database, any of which applies to the exemplary method depicted inFIGS. 2-4. The exemplary embodiment of creating a new database from arestored full backup image applies to the following discussion, althoughit also applies to creating a new database using a database loadutility, for example.

At 305 an amount of time required to restore the most recent fullbackup, referred to as Full Restore Time (FRT), may be determined in anyone of several ways, including for example, consulting a history ofrestore time information, or by calculating an estimated transfer ratebased on the amount of data to be restored.

In the course of normal activities, the DBA may schedule periodicincremental backups to capture changes in the database since theprevious backup of any type. At 310 an amount of time required torestore a particular incremental backup, referred to as IncrementalRestore Time (IRT), may be determined in any one of several ways,including for example, by observing an elapsed time between the startand completion of the incremental backup process that generated theincremental backup, or by consulting a history of restore timeinformation. Since one or more incremental backups may have beenperformed since the last full backup, at 310 the estimated time it maytake to apply all incremental backups may be represented by SUM_IRT,which is the sum of their individual restore times. The equivalentexpression is

${\sum\limits_{i = 1}^{n}{IRTi}},$

where n represents the number of incremental backups performed since thelast full backup. It should be noted that where the last type of backupwas a full backup, the value of

$\sum\limits_{i = 1}^{n}{IRTi}$

will be zero.

At 315 an estimated Incremental Backup Time (IBT) may be determined byestimating the IBT based on previous elapsed incremental backup times.

At 320, a Full Backup Time (FBT) may be estimated using metadata storedby the DBMS and associated with an already completed full backup.Additionally, a FBT may be estimated based on several factors, includingamong other things, the amount of data (e.g., in gigabytes) contained inthe database, the speed and configuration of the target storage devices,speed of the computer processor, amount of computer memory available,and the speed of the network.

At 330, a next backup may be an incremental backup or a full backup,depending upon the relationship between the RTO and the estimated timeto restore a full backup and any incremental backups, as determined bythe relationships of Calculation “1” (i.e., the recovery time is greaterthan or equal to the RTO). The sum of: estimated time to restore a fullbackup; the estimated time to restore any incremental backups includinga heuristic, for example an incremental backup time; perform a fullbackup; and complete a current incremental backup may be referred tocollectively as the recovery times.

The choice to perform an incremental or full backup may be influenced bywhether the database provides applications sufficient normal transactionprocessing time, referred to as unencumbered processing time, withoutcompeting for resources with an active concurrent backup process. If at330, the recovery time is greater than or equal to the RTO, then at 335,the DBMS may determine that there is enough time to create anotherincremental backup and still meet the RTO. The DBMS applies theheuristic, represented by the IBT, where there should be at least aminimum amount of unencumbered processing time between incrementalbackups. The IBT is doubled in the above formula, indicating that nomore than half the time between incremental backups should be used forperforming the incremental backup. In another exemplary embodiment, aheuristic other than incremental backup time may be used, including, forexample, a fixed time period. In the exemplary embodiment, the heuristicmay be a default value, which may be overridden by a user-suppliedvalue.

However, if at 330 the recovery time is less than the RTO, then at 340,the DBMS may estimate the time to complete a full backup, and determinethat to keep the database within the RTO a full backup should becreated.

Referring now to FIG. 4, the reference numeral 215 generally designatesa flow diagram illustrating an exemplary embodiment of a method ofdetermining when to initiate the next backup activity. The followingcalculation, discussed in detail during the discussion of FIG. 4,provides an exemplary calculation for determining when to initiate thenext backup:

$\begin{matrix}\left( {{FRT} + {\sum\limits_{i = 1}^{n}{IRTi}} + {RFT} + {BT}} \right) & \left( {{Calculation}\mspace{14mu} 2} \right)\end{matrix}$

At 405, the terms FRT and

$\sum\limits_{i = 1}^{n}{IRTi}$

(i.e., SUM_IRT) are substantially similar to the terms described abovewith reference to FIG. 3. The DBMS may determine an accumulatedRollforward Time (RFT), which may represent an amount of time needed toapply transaction log records that were generated since the lastincremental backup to the database.

In an exemplary embodiment, the RFT may be continuously calculated usingthe accumulated recovery cost statistics as recorded in the persistentstore, the metadata repository, or in one or more tables within acatalog, either at the database level or at the DBMS level. Thefollowing discussion describes an embodiment of recovery cost statisticsthat may be implemented in a DBMS system, such as DBMS 110 (FIG. 1), andthat may be used, for example, by the method 215 (FIG. 4).

A DBMS vendor identifies the recoverable operations that the DBMS mayperform, such as an insertion of a row of data or a creation of a table.A recoverable operation may be defined as an operation that changes thestate of database objects such as user data, or an operation thatchanges the state of database control structures such as one or morecatalog tables. A recoverable operation may further include one that theDBMS tracks using transaction log records so that the operation may berecovered. As a result, in the event of a DBMS service disruption, theDBMS may use the transaction log records in combination with existingfull and incremental backups, as needed, to restore the database to astate prior to the failure.

Having defined the recoverable operations in the DBMS, the DBMS vendormay now associate each recoverable operation with a value representing arecovery cost. A recovery cost value refers to an abstract unit thatrepresents the cost to recover a given recoverable operation in theDBMS. A recovery cost of a given operation may be expressed in unitsrelative to a base unit. Although it may be related to an amount of timeit takes to perform the recoverable operation, a recovery cost value isexpressed in units that are some multiple of a base operation, asdefined by the DBMS vendor. A base operation may be a recoverableoperation that requires the least amount of processing resource, e.g.,time to complete. For example, during benchmark testing, a DBMS vendormay establish that an insert of a row of data is the leastresource-intensive operation, and thus it is defined as the baseoperation and is assigned a recovery cost of “1” unit. If, for example,further benchmark testing establishes that creating a new table takes“6” microseconds (μs), where the base operation takes “2” μs, then thecreation of the new table may be recognized as taking three times longerto complete, and thus be assigned a relative recovery cost of “3” units.In this example, creating a new table may include inserting new entriesin several system catalog tables, creating an index for the new table,and inserting the new rows of data, whereas, in contrast, inserting arow of data may only consist of the one operation. Assigning the tablecreation operation a higher recovery cost relative to the base operationrecognizes the higher number of complex operations required to completethe table creation.

The DBMS vendor may provide the recovery cost values for recoverableoperations as one or more tables within a catalog, either at thedatabase level or at the DBMS level, as for example in Catalog Sample 1:

Catalog Sample 1 SystemCatalog.RecoveryCostOfOperations { OperationName// Type of operation, such as insert or delete row RecoveryCost //Number of recovery cost units to recover this operation OperationCount// Accumulated count of this operation }A default cost of each recoverable operation is determined by the DBMSvendor, and is based on the DBMS vendor's knowledge of the internalalgorithms and measurements used to implement the recoverableoperations.

In another exemplary embodiment, the DBMS vendor may group operations ofsimilar recovery cost values into classes for ease of management, as forexample, in Catalog Sample 2:

Catalog Sample 2 SystemCatalog.RecoveryClasses { ID // Class identifierClassName // E.g., low, medium, high CostRange // E.g., microsecond lowto microsecond high values OperationCount // Accumulated count ofoperations in this class }As an example, a DBMS may group the recoverable operations into classes,such as “low”, “medium”, and “high” according to the recovery cost. Inoperation, recovery objectives such as RTO and Recovery Point Objective(RPO) may frequently be expressed in terms of a scale magnitude, forexample, seconds, vs. minutes vs. hours. Therefore, the classes may bebased on a scale of magnitude of recovery cost. For example, recoverableoperations classified as “high” may be on an order of ten times morecostly to recover than those classified as “medium.” Similarly, “medium”class recoverable operations may be on an order of ten times more costlyto recover than those recoverable operations classified as “low” cost.Using a Structured Query Language (SQL) based interface, an end-userhaving sufficient authority to perform functions on the system catalogs,for example a DBA, may define, alter, or delete the recovery classes asdesired to architect a recovery plan that more closely reflects aparticular DBMS environment and business enterprise RTO/RPO goal.Additionally, during a subsequent product upgrade, the DBMS vendor maysupply updated recovery cost values to the system catalog tables thatmay reflect performance enhancements or other additional features in theDBMS.

The DBMS may allocate specialized processes (e.g., threads) to share andparallelize work, such as virtual memory management, data Input/Output,query processing, and monitoring recoverable operations as they occur.Thus the DBMS is implicitly aware of the types of recoverableoperations, such as for example an insert of a row of data, that aretaking place. The DBMS may include different code paths to execute andmanage each of the various recoverable operations. When a particularrecoverable operation, for example an insert of a row of data, isexecuted, then that specific logic, or code path, is invoked. As part ofthat logic, at 225 the DBMS may also update the persistent storage toincrement the count corresponding to the recoverable operation type. Inanother exemplary embodiment, at 220 the DBMS threads may synchronouslyparse the transaction log records as they are created. Or,alternatively, the DBMS threads may asynchronously act as backgroundprocesses to periodically scan the transaction log after the transactionlog records are written. The recoverable operations may be tracked forall databases in the DBMS, or alternatively, by some other unit ofrecovery, such as an application, a DBMS object, or individual tablespaces. Having encountered and identified a recoverable operation at220, the DBMS may then update the persistent store to increment thecount corresponding to the recoverable operation encountered.

For example, the recoverable operation of inserting a row of data mayoccur ten (10) times over a period of time. Thus, the count value forthis operation is ten (10). In one exemplary embodiment, the counts maybe accumulated and updated either by class, or by individual recoverableoperation, depending upon the level of granularity desired and theimplementation chosen by the business enterprise. An authorizedend-user, such as the DBA, may periodically review the counts ofrecoverable operations through the SQL interface to the DBMS.

Referring to FIG. 4, at 405 having recovered the database using the mostrecent backup, the RFT may be derived from the recovery cost statistics(i.e., the count values and the recovery costs) as accumulated since thelast backup and recorded in the one or more catalog tables, or otherpersistent store. The RFT derived here dynamically corresponds to thechanges to the database since the last backup. Using the above exemplarycatalog definition, for example Catalog Sample 1, RFT may be calculatedas the sum of (OperationCount×RecoveryCost) for each OperationName inthe Catalog Sample 1.

At 410, BT may refer to either a full backup or an incremental backup,as determined through the method 210 (FIG. 3). Where a full backup isplanned, a BT may be estimated based on several factors, including forexample, the historical transfer rate to the backup device, thehistorical full backup times, if available, and the size of thedatabase. Where an incremental backup is planned, the BT may beestimated from previous incremental backup times. If at 415 thecalculated estimated time to backup, restore, and recover a databaseequals or exceeds the RTO, then at 420 the DBMS issues a warning messageindicating that the database is out of compliance relative to the RTO,and at 425 the next backup is initiated upon completion of thecalculation.

However, if at 415 the calculated backup, restore, and recovery estimateis less than the RTO, then processing continues at 430, where anestimated time is calculated when the time to backup, restore, andrecover a database equals the RTO (i.e., Calculation 2). Havingcalculated a time when the time to backup, restore, and recover adatabase equals the RTO (i.e., Calculation 2), at 435 the backup isscheduled to start before that time.

Referring now to FIG. 5, computing device 500 may include respectivesets of internal components 800 and external components 900. Each of thesets of internal components 800 includes one or more processors 820; oneor more computer-readable RAMs 822; one or more computer-readable ROMs824 on one or more buses 826; one or more operating systems 828; one ormore software applications (e.g., DBMS modules 829) executing the method200; and one or more computer-readable tangible storage devices 830. Theone or more operating systems 828 and DBMS modules 829 are stored on oneor more of the respective computer-readable tangible storage devices 830for execution by one or more of the respective processors 820 via one ormore of the respective RAMs 822 (which typically include cache memory).In the embodiment illustrated in FIG. 5, each of the computer-readabletangible storage devices 830 is a magnetic disk storage device of aninternal hard drive. Alternatively, each of the computer-readabletangible storage devices 830 is a semiconductor storage device such asROM 824, EPROM, flash memory or any other computer-readable tangiblestorage device that can store a computer program and digitalinformation.

Each set of internal components 800 also includes a R/W drive orinterface 832 to read from and write to one or more computer-readabletangible storage devices 936 such as a CD-ROM, DVD, SSD, memory stick,magnetic tape, magnetic disk, optical disk or semiconductor storagedevice.

Each set of internal components 800 may also include network adapters(or switch port cards) or interfaces 836 such as a TCP/IP adapter cards,wireless WI-FI interface cards, or 3G or 4G wireless interface cards orother wired or wireless communication links. The DBMS 829 and operatingsystem 828 that are associated with computing device 500, can bedownloaded to computing device 500 from an external computer (e.g.,server) via a network (for example, the Internet, a local area networkor other, wide area network) and respective network adapters orinterfaces 836. From the network adapters (or switch port adapters) orinterfaces 836 and operating system 828 associated with computing device500 are loaded into the respective hard drive 830 and network adapter836. The network may comprise copper wires, optical fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers.

Each of the sets of external components 900 can include a computerdisplay monitor 920, a keyboard 930, and a computer mouse 934. Externalcomponents 900 can also include touch screens, virtual keyboards, touchpads, pointing devices, and other human interface devices. Each of thesets of internal components 800 also includes device drivers 840 tointerface to computer display monitor 920, keyboard 930 and computermouse 934. The device drivers 840, R/W drive or interface 832 andnetwork adapter or interface 836 comprise hardware and software (storedin storage device 830 and/or ROM 824).

As will be appreciated by one skilled in the art, aspects of the presentdisclosure may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present disclosure may take theform of an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present disclosure may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent disclosure may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages, a scripting language such as Perl, VBS or similarlanguages, and/or functional languages such as Lisp and ML andlogic-oriented languages such as Prolog. The program code may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider).

Aspects of the present disclosure are described with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of thedisclosure. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in FIGS. 1-5 illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

What is claimed is:
 1. A method for optimizing the number and type ofdatabase backups to achieve a given recovery time objective (RTO), themethod comprising: receiving, by the DBMS, a heuristic for determiningan amount of unencumbered processing time and an RTO; determining a typeof next backup corresponding to a next backup, wherein the type of nextbackup is an incremental backup when a sum of recovery times totals lessthan the received RTO, else the type of the next backup is a fullbackup; and scheduling a time for the next backup based on the receivedRTO being a total of: an amount of time to complete the type of nextbackup; an amount of time to rollforward zero or more transaction logrecords wherein the amount of time to rollforward is calculated as:tracking and storing, in a persistent storage, a count and type ofrecoverable operations as they occur during database execution;extracting from the persistent store a recovery cost associated witheach of the recoverable operations; and for each of the recoverableoperations, multiplying the count by the associated recovery cost; andan amount of time to restore at least one backup.
 2. The method of claim1, wherein the sum of recovery times further comprises a total of: anamount of time required to restore a latest full backup, an amount oftime to restore zero or more incremental backups, an amount time tocomplete a current incremental backup, an amount of time correspondingto the heuristic; and an amount of time to complete a full backup. 3.The method of claim 1, wherein determining the type of next backupfurther comprises: calculating a total amount of time by aggregating: anamount of time to restore a full backup; the amount of time to restorezero or more incremental backups; the amount of time to complete anincremental backup; the amount of time to complete a full backup; anddetermining the type of next backup based on the calculated total amountof time and the received RTO.
 4. The method of claim 1, whereindetermining a time to schedule the next backup further comprises: whenthe received RTO is less than the total of: the amount of time tocomplete the type of the next backup; the amount of time to rollforwardthe zero or more transaction log records; and the amount of time torestore the at least one backup; issuing a message that the database isout of compliance with the received RTO; and determining to start thenext backup immediately.
 5. The method of claim 1, wherein the amount ofunencumbered processing time is an amount of processing time duringwhich a transaction executes without competing for resources with anactive concurrent backup process.
 6. The method of claim 1, wherein therecovery cost comprises a number of units wherein each of the number ofunits is a multiple of base operations, and wherein a base operation isa least resource-intensive operation in the DBMS.
 7. The method of claim1, further comprising: grouping recoverable operations into a pluralityof recovery classes, wherein each of the plurality of recovery classesincludes: a class identifier; a class name, wherein the class namecorresponds to a grouping of recoverable operations by recovery cost; acost range, wherein a range of the cost range begins at a low and endsat a high value; and an operation count, wherein the operation count isan accumulated count of recoverable operations in a class.
 8. The methodof claim 7, wherein a content and a number of the plurality of recoveryclasses is customizable.